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DETAILED ACTION 

This Office action is in response to Applicant's amendment and request for 
reconsideration filed on May 22, 2006. Claims 1-4, and 9-49 are presented for further 
examination. All independent claims have been amended. Claims 36-49 are new. 

Response to Arguments 
Applicant's arguments are moot in view of the new grounds of rejection set forth. 

Claim Rejections - 35 USC § 101 
35 U.S.C 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

5. Claim 49 is rejected under 35 U.S.C, 101 because the claimed invention is directed to 
non-statutory subject matter. 

Claim 49 is not tangibly embodied on a proper storage medium. The claim appears to recite 
"electromagnetic signals" as a medium. Electromagnetic signals are not statutory subject matter 
as set forth in the latest "Interim Guidelines for Examination of Patent Applications for Patent 
Subject Matter Eligibility" (signed October 26 th , 2005) which further clarifies computer- related 
nonstatutory subject matter on pages 50-57. 

<http://www.uspto.gov/web/ofFices/pac/dapp/opla/preognotice/guidelinesl01_2005 1026.pdf> 



Claim Rejections - 35 USC § 103 
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The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

1. Claims 1-4 and 9-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Martin et ah (U.S. Patent Number 6,765,927, hereinafter "Martin") and the Real-Time 
Streaming Protocol (RTSP) RFC 2326 (hereinafter RTSP) and The Use of RSVP with 
IETF Integrated Services RFC 2210 (hereinafter RSVP'2210) and Resource ReSerVation 
Protocol (RSVP) - Version 1 Functional Specification RFC 2205 (hereinafter RSVP' 2205) 
and SDP: Session Description Protocol RFC 2327 (hereinafter SDP). 

In considering claims 1, 9, Martin discloses an intermediate network device for use 
within a computer network having a server configured to provide one or more data streams to a 
client, each stream having a corresponding bandwidth, the network device comprising: 

□ means for determining network traffic characteristics sufficient to identify a stream 
from the server to the client (Col 3, lines 21-24); 

□ a resource reservation protocol (RSVP) transmitter proxy (Col 3, line 12) configured 
to reserve resources within the computer network on behalf of the server for 
allocation to the stream (Col 2, line 62 "flow characteristics" and Col 3, lines 23-27). 

Note the use of RSVP'2210, RSVP'2205, RTSP, and SDP in combination was explicitly 
disclosed in the RFCs themselves and thus would have motivated one of ordinary skill in the art 
at the time of Applicant's invention to use them in combination in order to provide a reliable and 
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efficient data flow to end users. Furthermore Martin disclosed the use of RSVP within his 
system and specifically left his system open ended to work with any flow (Col 3, lines 15-17, 47- 
54 and Col 8, lines 4-10). Thus it would have been obvious to one of ordinary skill in the art at 
the time of Applicant's to utilize RSVP, RTSP, and SDP within Martin's system in order to 
provide a reliable and efficient data flow to end users. 

Martin disclosed the invention substantially as claimed however, Martin failed to 
specifically recite snooping packets to determine the bandwidth of the stream from RTSP 
response messages. Nonetheless Martin specifically disclosed snooping packets to generate a 
proper RSVP Path message which includes both a TSPEC and ADSPEC in order to reserve the 
required resources for the flow (see inter alia, Col 3, lines 21-27 and Col 5, lines 1-10). As 
disclosed by RSVP'2210 section 3.1 the TSPEC and ADSPEC objects include a bandwidth field. 
Thus, it would have been obvious to one of ordinary skill in the art at the time of Applicant's 
invention to snoop any packet in the flow to determine the bandwidth of the flow for the TSPEC 
and ADSPEC objects in order to generate a proper RSVP path message. Further as evidenced by 
at least SDP, the RTSP describe response messages (which contain an SDP) include a field that 
describes the bandwidth of the flow (see SDP the Bandwidth section field b which specifies the 
proposed bandwidth). Since the RTSP describe response messages include the bandwidth of the 
flow it would have been obvious to one of ordinary skill in the art at the time of Applicant's 
invention to snoop RTSP describe response messages to determine the bandwidth information of 
the flow, in order to generate a proper RSVP path message (and associated TSPEC/ ADSPEC) as 
Martin requires. 
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In considering claim 2, Martin discloses the intermediate network device of claim 1 
wherein the RSVP transmitter proxy is configured to generate and send one or more RSVP Path 
messages on behalf of the server, the one or more RSVP Path messages containing the network 
traffic characteristics and the bandwidth of the stream (Col 3, lines 23-27). 

In considering claim 3, Martin discloses the intermediate network device of claim 2 
wherein the RSVP transmitter proxy is configured to terminate RSVP Reservation (Resv) 
messages that are sent to the Server (Col 3, lines 42-46). [Figure 1 also shows a clear illustration 
of where the Resv messages travel, from the client (Component 120) to termination at the proxy 
server (Component 140).] 

In considering claim 4, Martin discloses an RSVP host proxy which is capable of 
generating RSVP Path messages and receiving RSVP Resv messages on behalf of a server as 
stated above. However, Martin fails to disclose an RSVP host proxy which is capable of 
generating RSVP Path Teardown messages on behalf of a server. Nonetheless, the use of RSVP 
Path Teardown messages is well known, as referenced by RFC 2205. 

Martin discloses that the RSVP host proxy supports the RSVP protocol set forth in RFC 
2205 (Martin Col 3, lines 1-5). Section 2.4 of RFC 2205 discusses the use of RSVP Path 
Teardown messages within the RSVP protocol. RFC 2205 goes on to recommend "that all end 
hosts send a teardown request as soon as an application finishes" (Section 2.4, paragraph 1). 
Thus, giving the teachings of RFC 2205, it would have been obvious to a person having ordinary 
skill in the art to design the Martin system to support RSVP Path Teardown messages, since the 
messages are recommended by the RSVP protocol. 
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In considering claim 10, Martin discloses the intermediate network device of claim 9 
further comprising a session manager configured to store the network traffic characteristics and 
bandwidth of the stream (Col 4, lines 27-29). 

In considering claim 1 1, the RTSP protocol discloses an RTSP state manager which 
includes one or more state machine engines, configured to maintain the RTSP state of the stream 
(RFC 2326, Appendix A. 2). 

In considering claim 12, Martin discloses the intermediate network device of claim 2 
wherein 

□ the client has a network layer address and a transport layer port for use in receiving 
the stream from the server (Col 4, line 59-61; included in a Path message), 

□ the server has a network layer address and a transport layer port for use in sending the 
stream to the client (Col 4, line 59-61), and 

□ the network traffic characteristics include the client's network layer address and 
transport layer port and the server's network layer address and transport layer port 
(Col 4, line 59-61). 

In considering claim 13, Martin discloses the intermediate network device of claim 12 
wherein the stream uses a given transport layer protocol, and the network traffic characteristics 
include the given transport layer protocol (Col 4, line 59-61). 

In considering claim 14, Martin discloses the intermediate network device of claim 13 
wherein the RSVP Path messages generated and sent by the RSVP transmitter proxy on behalf of 
the server include a session object containing the client's network layer address and transport 
layer port and the transport layer protocol associated with the stream (Col 4, line 59-61). 



Application/Control Number: 09/940,753 Page 7 

Art Unit: 2153 

In considering claim 15, Martin discloses the intermediate network device of claim 14 
wherein the RSVP Path message includes a sender template object containing the server's 
network layer address and transport layer port associated with the stream (Col 4, line 59-61). 

In considering claim 16, Martin discloses the intermediate network device of claim 15 
wherein the RSVP Path message includes a sender Tspec object containing the bandwidth of the 
stream (Col 5, line 4). 

2. Claims 17-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Martin 
and the Real-Time Streaming Protocol (RTSP) RFC 2326 (hereinafter RTSP) and The Use 
of RSVP with IETF Integrated Services RFC 2210 (hereinafter RSVP'2210) and Resource 
ReSerVation Protocol (RSVP) - Version 1 Functional Specification RFC 2205 (hereinafter 
RSVP' 2205) and SDP: Session Description Protocol RFC 2327 (hereinafter SDP) and 
"Format of the RSVP DCLASS Object" Request for Comment 2996 (hereinafter RFC 
2996), 

In considering claim 17, claim 17 is rejected using similar rationale as set forth with 
regard to claim 1 . 

In further considering claims 17-19 and the use of DSCP, as discussed above Martin 
disclosed a means for obtaining the stream bandwidth and a means for including the obtained 
bandwidth within an RSVP Path message Tspec object. However, Martin fails to disclose a 
means for obtaining a differentiated services codepoint (DSCP) value that is based on the 
bandwidth of the stream. Martin also fails to disclose the intermediate network device of claim 
17 wherein the RSVP transmitter proxy is configured to load the DSCP into the RSVP Path 
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message generated and sent on behalf of the server. Martin further fails to disclose the 
intermediate network device of claim 18 wherein the RSVP Path message includes a DCLASS 
object containing the DSCP. 

Nonetheless, the use of RSVP Path messages that contain differentiated services 
codepoint (DSCP) values within DCLASS objects was well known as evidenced by RFC 2996 
(Abstract). In an analogous art, RFC 2996 disclosed the use of DCLASS objects within RSVP 
messages in order to enhance the manageability of application traffic QoS in a differentiated 
service network (RFC 2996 Abstract). Thus, it would have been obvious to one of ordinary skill 
in the art to design the Martin system to obtain a differentiated services codepoint (DSCP) value 
that is based on the bandwidth of the stream, in order "to enhance the manageability of 
application traffic QoS in a differentiated service network" (RFC 2996, Abstract). Further, it 
would have also been obvious to include within an RSVP path message, the determined DSCP 
value in a DCLASS object, given that such usage is disclosed in the RFC 2996 protocol and 
would enhance the manageability of application traffic QoS in a differentiated service network 
(RFC 2996, Abstract). 

3, Claims 22-25, 27, 29-32, 34, 36, 38-40, 42-44, 46-49 are rejected under 35 U.S.C 103(a) 
as being unpatentable over Martin and the Real-Time Streaming Protocol (RTSP) RFC 
2326 (hereinafter RTSP) and The Use of RSVP with IETF Integrated Services RFC 2210 
(hereinafter RSVP'2210) and Resource ReSerVation Protocol (RSVP) - Version 1 
Functional Specification RFC 2205 (hereinafter RSVP'2205) and SDP: Session Description 
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Protocol RFC 2327 (hereinafter SDP) and Merwe et al. (mmdump: A tool for Monitoring 
Internet Multimedia Traffic; hereinafter Merwe). 

In considering claims 22-24, 29-31, 36, 38-40, 42-44, and 46-49 these claims are rejected 
using a similar rationale as applied to claim 1 and in view of the following. Martin disclosed the 
invention substantially as claimed however Martin failed to specifically recite receiving a 
message from a client to a server, wherein the client message requesting that the server begin 
sending a traffic flow to the client. Further Martin failed to specifically recite receiving a 
response message from the server, the response message responding to the message from the 
client. Nevertheless Martin disclosed the detection of a flow from a server to a client (Col 3, 
lines 15-20). Further it was also well known in the art at the time of the invention to detect the 
start of a flow based on a client request and server response, as evidenced by Merwe. In an 
analogous art, Merwe disclosed a system for monitoring multimedia traffic flows using the RTSP 
protocol (abstract). The Real Time Streaming Protocol (RTSP) is the dominant control protocol 
for controlling the streaming of content on the Internet (Sect. 2.2). Merwe' s system detects client 
requests for the server to begin sending a traffic flow (RTSP describe message) and the 
corresponding server response (media specific information about the stream) (Section 2.2 and 
Figure 1). It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify Martin's system to detect traffic flows based on the client request and server 
response pair of RTSP as disclosed by Merwe (Section 2.2), since the RTSP protocol is the 
dominant control protocol for streaming content on the Internet (Merwe Sect 2.2. 1 st U). 

In considering claims 25, 27, 32, and 34, Martin disclosed means for reading (snooping) 
messages received by the router parameters of a traffic flow, the traffic flow requested by the 
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client for the server to transmit to the client (determining that the data packet meets RSVP sender 
host proxy criteria) (Col 3, lines 21-22). 

4. Claims 28 and 35 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Martin and the Real-Time Streaming Protocol (RTSP) RFC 2326 (hereinafter RTSP) and 
The Use of RSVP with IETF Integrated Services RFC 2210 (hereinafter RSVP'2210) and 
Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification RFC 2205 
(hereinafter RSVP' 2205) and SDP: Session Description Protocol RFC 2327 (hereinafter 
SDP) and Merwe et ah (mmdump: A tool for Monitoring Internet Multimedia Traffic; 
hereinafter Merwe) as applied above and further in view of Gai et al. (RSVP Proxy - 
Internet Draft; hereinafter Gai). 

In considering claims 28 and 35, as discussed above Merwe disclosed receiving first 
message by the router, the first messages originating from computers connected to the Internet 
and directed to the server (Sect. 2.2, DESCRIBE message) and receiving second messages by the 
router, the second messages originating from the server and directed to client connected to the 
internet (Sect. 2.2. server response - media specific information). However both Martin and 
Merwe failed to specifically recite connecting the router one hop away from the server. In an 
analogous art, Gai disclosed an RSVP Sender Proxy (see Section 3) analogous to Martin's proxy. 
Gai disclosed the router (RSVP proxy) is one hop away from the server (Figure 1) such that the 
most Path message enabled additional downstream network elements can benefit from the 
information carried in the signaling messages (Section 4, Where to Proxy). It would have been 
obvious to one of ordinary skill in the art at time of the invention to incorporate the teachings of 
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Gai within the combined Martin and Merwe system so that the most Path message enabled 
downstream network elements can benefit from the information carried in the signaling messages 
(Gai Section 4, Where to Proxy). 

Allowable Subject Matter 
Claims 37, 41, and 45, would be allowable if rewritten to include all of the limitations of 
the base claim and any intervening claims. Claims 26 and 33 are allowed. 

Conclusion 

1 . The prior art made of record, in PTO-892 form, and not relied upon is considered pertinent 
to applicant's disclosure. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sean Reilly whose telephone number is 571-272-4228, The 
examiner can normally be reached on M-F 8-5. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glen Burgess can be reached on 571-272-3949. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 




